Fun experiment: an explorable toroidal world - #139

@Giszmo can we split the difference and make the torus zoom-out and snap-back mode configurable? I've found it very awkward in my testing

@Giszmo The two navigation styles are now supported through Settings → General Settings → Automatic torus view from the main menu. It is off by default, preserving explicit G switching. Enabling it gives gradual folding while scrolling and a quick return after movement stops; G keeps the overview open. The preference is saved locally, and automatic transitions wait for selection/painting gestures to finish. Software rendering stays in 2D.

Further profiling on a 256 × 256 map also exposed redundant cloud generation and sprite submission overhead. The rendering benchmark improved from about 130 ms to 12–16 ms per frame on the M3, with the map still refreshing every frame. GPU and software checks pass, including pixel comparisons for the resource batching change.

Thanks for explaining the Wayland failure. I understand that it belongs to master’s fullscreen scaling rather than this feature. I’d like to keep this PR independent and focused while #129 and #132 are still pending, rather than coupling it to that larger dependency chain. This leaves the Wayland issue outstanding here until the separate scaling work lands.

You could also help make those other improvements land ;)

Try your torus world with extreme map geometries. Out of the box a 64x128 map looks like this here:

For comparison, a 512x64 looks like this:

@Giszmo I've moved this PR to draft for now and merged current master, including the refactoring and fullscreen-scaling work now that those PRs have landed. The torus integration follows the new GUI/render modules and separate viewer and pending-building state. Explicit G switching remains the default, with automatic folding off by default in the main Settings menu.

The integration also caught a nearest-neighbour sampling mismatch between standalone and atlas resource sprites; that is fixed, with identical pixels at native, reduced and enlarged scales. Local OpenGL and software-only build/rendering checks pass, as do the broader test executables and the selection/terrain regressions. The 256 × 256 rendering benchmark remains about 12 ms per frame with clouds on the M3 (rendering only).

I'll keep the draft current with master and resolve integration conflicts as they arise. Native Wayland playtesting of the combined changes is still needed.

@Giszmo Thanks for the rectangular-map examples. Addressed in 1016f0b: the torus ring/tube proportions now follow the map dimensions, with isothermal texture coordinates so tiles stay locally square on the surface. Wide maps produce thinner rings and tall maps produce fatter ones. Tile area still changes around the tube, and perspective still foreshortens it.

The geometry is shared by rendering, clouds and picking; the fitting/mesh caches also account for map aspect ratio. Mesh size stays fixed. I checked 64 × 128, 512 × 64, 64 × 512 and square terrain grids, including transitions, wrapped picking and changing map dimensions. OpenGL and software-only builds/rendering pass, as do geometry/picking tests under ASan/UBSan. The 256 × 256 Oazis rendering benchmark measured 16.64 ms median with clouds in this run on the M3 (rendering only).

Keeping this in draft and current with master while the revival work settles. Manual mode switching remains the default, automatic folding remains opt-in in the main Settings menu, and native Wayland playtesting is still outstanding.

Visual evidence for the map-proportion fix in 1016f0b. These are actual OpenGL renders using the benchmark’s synthetic checkerboard terrain, which makes tile proportions easier to compare. Dimensions below are map width × height.

Tall map — 64 × 128	Square map — 128 × 128	Wide map — 512 × 64

Tall maps produce a fatter tube and wide maps a thinner ring. The visual priority is square-looking tiles in the visible, camera-facing region. The mapping preserves local surface proportions; perspective still compresses tiles as the surface turns away, and tile area varies around the tube. Distortion at the sides and inner opening is less important than readability in the main visible region. Click an image for full resolution.

To reproduce, build torus-render-benchmark and run with GLOB2_BENCH_SIZE=64x128, 128x128, or 512x64, and GLOB2_BENCH_CAPTURE=/tmp/torus.ppm. These images illustrate the geometry; the automated rendering, picking and software-path validation is described in the preceding comment.

Maintenance update: merged master through 95de302 in 3cc46b1 and resolved the conflicts with the identifier cleanup, fullscreen letterboxing, and new game-speed settings. Both settings are available without overlapping; manual G switching remains the default and automatic torus folding stays off by default.

The Linux/Windows failure on 1016f0b was a numerically unstable finite-difference test on the very small inner wall of a tall-map torus. I reproduced it locally with fused multiply-add disabled and increased the sampling interval without relaxing the accuracy threshold or changing the renderer. Geometry and picking now pass locally with FMA disabled and with ASan/UBSan.

OpenGL and software-only builds/rendering, software-only startup with GPU mode requested, rectangular-map fitting/picking, fullscreen aspect-ratio checks, game-speed controls/playback, and the selection, terrain, wrapped-building, entering-unit and savegame regressions pass locally. Resource-atlas comparisons still have zero differing pixels. The latest 256 × 256 rendering-only benchmark measured 11.4 ms median with clouds on the M3. CI is running for the new merge; the PR remains draft, and native Wayland playtesting is still outstanding.

Note/question: did you consider rendering the units in 3D? The repository has the 3D models of the globules in Blender.

Also, we could try to see if there exist tools to create 3D models from 2D images, for the other elements.

That could create a small world/little planet style.

Of course, this would make the two rendering paths (2D and torus) very different and thus increase the load time if done naively, but probably some on-demand loading could be done.

Note/question: did you consider rendering the units in 3D? The repository has the 3D models of the globules in Blender.

That would be a separate PR but of course, wrapping a 3D world into a torus might have extra challenges compared to the mere 2D wrapping.

Visual evidence for the map-proportion fix

That checkered torus images are a great way to visualize the problem. I would tilt the torus though to fill the screen's aspect ratio or even allow it to crop left and right to focus more on the front facing landscape.

wrapping a 3D world into a torus might have extra challenges compared to the mere 2D wrapping.

Without thinking too much about it, I do not expect to be too hard to transform an (x, y, z) coordinate (for z << x or y) onto the torus coordinates. I imagine we can do that on the shader itself. Because you basically take (x, y), map it on the torus 3D point, then multiply z with the unitary normal at that point, and voilà.

@Giszmo Addressed the tilt suggestion in 0e4524d. The camera now fits the torus silhouette to the playable area’s aspect ratio instead of forcing a steep view to keep the hole visible. This gives the front-facing landscape more room; wheel zoom still allows a closer view with cropped sides. The local square-tile mapping is unchanged.

Updated actual renders, with map width × height:

64 × 128	128 × 128	512 × 64

Shallow angles also exposed precision loss when picking narrow projected triangles. The barycentric calculation now uses double precision, with coverage across portrait and wide windows, map shapes, and transitions. OpenGL and software-only builds/rendering, software-only startup with GPU requested, ASan/UBSan geometry/picking checks with FMA disabled, the terrain regression and all 158 CppUnit tests pass locally. The 256 × 256 rendering-only benchmark measured about 15.4 ms median with clouds on the M3 in this run.

Master is merged through b47c7d2 in the separate merge commit e155753. The previous Linux/Windows CI run passed; new checks are running. Keeping the PR draft and automatic folding off by default. Agreed that 3D unit models belong in a separate PR; this one continues to reuse the sprite renderer.

Can you render how 64x512 would look? I'd tilt the 512x64 much flatter. When you zoom out, you still care about what was the center of screen and in this case it drifts off very far.

I assume the 64x512 case would need an extreme ellipsis rotated around the center instead of a circle.

@Giszmo The screen-center drift and flatter wide-map view are addressed in a5a9491. The map position at the center of the 2D view stays anchored throughout the single smooth transition. The 512 × 64 view is now much flatter (about 19.5° here), and the surface at the focus faces the camera so its projected tiles stay close to square. The geometry and picking code share that anchor, with regression coverage for the transition and rectangular maps.

Here are actual OpenGL checkerboard renders from that commit, width × height:

64 × 512	512 × 64

We compared an elliptical cross-section and kept the circular shape after visual testing. The 64 × 512 case still has a very small inner opening and substantial variation in tile area around the tube; readability at the camera-facing focus is the priority.

Master is now merged through f50ab27 in 708a65d, with build/CI conflicts resolved. Local OpenGL and software rendering checks, geometry/picking sanitizer checks, all 170 unit tests, the standalone tests, and the terrain, gradient and team-statistics regressions pass. Fresh Linux/Windows CI will also check the software-only build. Automatic folding remains off by default in the main Settings menu, with G switching available. The PR is ready for review again; native Wayland playtesting is still outstanding.